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Abstract 


The Path Computation Element Communication Protocol (PCEP) enables 
communications between a Path Computation Client (PCC) and a PCE, or 
between two PCES. RFC 5440 defines the Include Route Object (IRO) to 
specify network elements to be traversed in the computed path. The 
specification does not specify if the IRO contains an ordered or 
unordered list of subobjects. During recent discussions, it was 
determined that there was a need to define a standard representation 
to ensure interoperability. It was also noted that there is a 
benefit in the handling of an attribute of the IRO’s subobject, the L 
bit. 


This document updates RFC 5440 regarding the IRO specification. 
Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7896. 
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Introduction 


The Path Computation Element Communication Protocol (PCEP) enables 
communications between a Path Computation Client (PCC) and a PCE, or 
between two PCEs. [RFC5440] defines the Include Route Object (IRO) 
to specify network elements to be traversed in the computed path. 
The specification does not specify if the IRO is an ordered or 
unordered list of subobjects. In addition, it defines the L bit as 
having no meaning within an IRO. 


[RFC5441] describes the use of an IRO to indicate the sequence of 
domains to be traversed during inter-domain path computation. 


During recent discussions, it was determined that there was a need to 
define a standard representation to ensure interoperability. 


This document updates the IRO specifications in Section 7.12 of 
[RFC5440]. 


Update in the IRO Specification 


Section 7.12 of [RFC5440] describes the IRO as an optional object 
used to specify a set of network elements to be traversed in the 
computed path. It states that the L bit in the subobject has no 
meaning within an IRO. It does not mention if the IRO contains an 
ordered or unordered list of subobjects. 


1. Update to RFC 5440 


The IRO specification is updated to remove the last line in the 
Section 7.12 of [RFC5440], which states: 


"The L bit of such sub-object has no meaning within an IRO." 


Further, Section 7.12 of [RFC5440] is updated to add the following 
two statements at the end of the first paragraph. 


- The content of an IRO is an ordered list of subobjects 
representing a series of abstract nodes (refer to Section 4.3.2 of 
[RFC3209]). 


- The L bit of an IRO subobject is set based on the loose or strict 
hop property of the subobject; it is set if the subobject 
represents a loose hop. If the bit is not set, the subobject 
represents a strict hop. The interpretation of the L bit is as 
per Section 4.3.3.1 of [RFC3209]. 
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3. Operational Considerations 


Because of the lack of clarity in [RFC5440], it is possible to 
encounter implementations that always interpret the IRO subobjects as 
loose. When these implementations interwork with an implementation 
conforming to this document, the following impact might be seen: 


o If a non-conforming (to this document) PCC sends an IRO to a 
conforming (to this document) PCE, then the PCE may unexpectedly 
fail to find a path (since the PCC may think of the IRO subobjects 
as loose hops, but the PCE interprets them as strict hops). 


o If a conforming PCC sends an IRO containing strict hops to a non- 
conforming PCE, then the PCE may erroneously return a path that 
does not comply with the requested strict hops (since the PCE 
interprets them all as loose hops). The PCC may check the 
returned path and find the issue, or it may end up using an 
incorrect path. 


4. Security Considerations 


This update in the IRO specification does not introduce any new 
security considerations, apart from those mentioned in [RFC5440]. 
Clarification in the supported IRO ordering or Loose hop bit handling 
will not have any negative security impact. 


It is worth noting that PCEP operates over TCP. An analysis of the 
security issues for routing protocols that use TCP (including PCEP) 
is provided in [RFC6952]. 
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